The invention has application in the field of network traffic generators and analyzers. More particularly, the invention is directed to a mechanism to insert TCP checksum information in the payload portion, typically, near the end of the a packet, in a protocol neutral way.
Network traffic generators and analyzers are devices used to provide information for use by network administrators to determine the efficiency of the flow of packets over a network and to determine where network bottlenecks exist or may exist. For example, a network, such as a local area network (LAN) or wide area network (WAN) will have connected at several nodes of the network, a network traffic generator which generates packets, which packets are generated using a predetermined software protocol such as IP, IPX, SPX, ICMP, ARP, or RARP, AppleTalk, DECNET or SNA, each of which is defined in an industry standard manner. The software or data communications protocols noted above are independent of the media access control (MAC) utilized such as Ethernet or Token Ring.
It is necessary to have a TCP checksum associated with each data packet so that when the packet is received by a receiving unit, the checksum in the packet can be compared with a checksum calculated when the packet is received to verify that the packet was properly received. With reference to FIG. 1, the TCP checksum is the 16 bit one""s complement sum over the TCP header (exclusive of the TCP checksum field itself) and payload portion, i.e., upper layer protocol information., of the packet plus the pseudo header portion.
Each packet is generated by a computer or other device and includes a network protocol portion, i.e., IP header and TCP header and a payload portion, i.e., upper layer protocol information. The TCP checksum is a value calculated based upon information contained in the TCP header and payload portion and part of the IP header portion referred to as the pseudo header. When a packet is received, a receiving unit recalculates the checksum using the data in the pseudo header, TCP header and payload portion of the packet. The calculated checksum is then compared with the checksum in the TCP header. If the two values do not agree, then it is assumed that the packet was transmitted in error and, typically, a request is made to have the packet re-transmitted.
In the prior art, when a frame is received by a network analyzer, in order to calculate the TCP checksum, it is necessary to store the entire frame which may be up to 65535 bytes. That is, since the TCP checksum is located within the TCP header, and since the TCP calculation includes bits which are near the end of the frame, the TCP header with the calculated TCP checksum cannot be transmitted until the entire frame portion needed for the TCP checksum calculation has been received and processed. Since the end of the frame may be many thousand of bytes from its beginning where the TCP checksum is located, the entire frame must be stored while the checksum is being calculated. Then once the TCP checksum has been calculated, the frame must be retrieved from storage and the calculated TCP checksum inserted into the TCP header where indicated at which time the frame can be transmitted. Thus, in addition to the memory required to hold the frame while the checksum is being calculated, additional hardware and processing is needed to perform two data transfer such as DMA (direct memory access) operations, one to store the frame while the checksum is being calculated, and one to retrieve the frame after the calculation has been completed so that the TCP checksum can be inserted into the TCP header and the frame can be transmitted.
The invention is directed to a method and apparatus for calculating and inserting a TCP checksum neutralizing value into a network data packet in a manner which minimizes storage requirements and processing time used to process the data packet. In one embodiment, a TCP checksum is calculated as a data packet is being received, up to the checksum field. The calculated checksum is then inserted into the checksum field. Then a calculation is performed on the remaining fields used to calculate the TCP checksum. The inverse of this second calculation is then stored in a normally unused portion of the payload portion of the data packet near the end of the packet. In this manner, when the packet is received and the TCP checksum is calculated, since the inverse of the fields which were not used to calculate the checksum in the TCP header is in the payload portion, their contribution to the checksum is negated so that a comparison of the calculated checksum and the stored TCP checksum will match, assuming the packet was properly received.